home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Libris Britannia 4
/
science library(b).zip
/
science library(b)
/
PACKET
/
MBL514.ZIP
/
NOTES
< prev
next >
Wrap
Text File
|
1988-08-07
|
23KB
|
633 lines
So far no detailed documentation is available for MBL512. What exists are
a series of change notes from WA7MBL to W3IWI. These are not intended for the
novice or faint at heart! In testing 5.12 we went thru several intermediate
releases, so in some cases a change may be rescinded by a later change. This
file is an edited version of all change notes combined. If a feature doesn't
work as described herein, it may be an old change that survived the editing.
This material, plus the NOTES.IWI file provided by Tom Clark is all the
written information that exists at this time.
Anyway, here goes:
==============
There is a new driver to load (JLIST.COM) along with BTRIEVE, DVTIMER, and
one of the COMBIOS/DVBIOS series of I/O drivers. Failure to load JLIST may
cause the BBS to hang.
See the file NOTES.IWI for some setup suggestions. NOTES.IWI also contains
a sample configuration file.
------------------
Converting from version 3.31 or 4.31
There are a number of programs included for converting user and mail
files from version 331/431.
CVTMAIL creates MAILFILE.BTR from BBSMAIL.BTR. It reads the existing
message text, and will prompt for the pathname of your present
mail directory (\BBS\MAIL\ or whatever).
Be sure to add the trailing backslash!
CVTUSER creates USERFILE.BTR from BBSUSER.BTR.
CVTBULL creates BULLSTNS.BTR from BBSBULL.BTR.
MKBFWD creates a blank BULLFWDS.BTR file.
----------------------
If you are starting from scratch (lots of luck!)
MKMAIL creates a blank MAILFILE.BTR file.
MKUSER creates a blank USERFILE.BTR file.
MKBULL creates a blank BULLSTNS.BTR file.
MKBFWD creates a blank BULLFWDS.BTR file.
----------------------
BULLSTNS.BTR contains a list of BBS callsigns and their assigned BBS #.
BULLFWDS.BTR contains the list of @BBS forwarding designator mnemonics
(such as ALLBBS, MBLBBS, NET, ARRL, etc) and the #s of the BBSs which
will receive that group.
There is a program called CKFWD, which will add information to the
BULLFWDS file. It will ask for the name of a Forwarding File.
It will read the file looking at BBS callsigns and checking to see
if they have a BBS # assigned. If so, it will look for any $ARRL type
lines and create or update the record for that forwarding designator to
add the indicated BBS. You can run this on a number of forwarding files
if desired.
The BBS command 'DF' (Display Forwarding lists) will show you which
BBSs are on which lists.
The DF command has been enhanced so 'DF ARRL' will show which stations
are on the $ARRL list.
An EF command has been added so 'EF ARRL' can be used to add/delete an
entire list, or to edit individual BBS stations.
The syntax is sorta kludgey, but it works as follows
Local> ef arrl
EDIT: Y to delete <cr> to retain:
Keep W1XYZ :
Keep W3IWI :
Add WA7MXZ :
Keep W1AW :
You will be shown ALL BBS callsigns that have been assigned BBS numbers in
your BULLSTNS (as shown by the D$ command). If they are already on the
list, the prompt will be "Keep W1XXX" and if not on the list will be "Add
W1XXX". To add one, type a Y. To delete one that is already on the list
type N. A <cr> will maintain the status quo.
You can then do a "df arrl" to be sure everything worked ok.
NOTE: Editing this list does NOT change the status of a bulletin (fully
forwarded). If a bulletin has been flagged as fully forwarded it will NOT
go to an added station. If a bulletin has not been flagged, it will go.
If a bulletin came in to a new list which didn't exist, it will have been
flagged as not-forwarding (no where to go), but will not be flagged as
fully forwarded (cuz you didn't forward it anywhere).
If you do want a non-expired bulletin to go to a new BBS (or a new list in
the case where you didn't have a list set up), if you EDIT the message
using the E nnnnn command and CHANGE the @BBS info (simply type in the
same @BBS info), it will then check the BULLFWDS file and if there are
stations that have not received the bulletin it will set the internal
flags for the bulletin to attempt to forward again (and reset the fully
forwarded flag if necessary).
The syntax of the forwarding file has been changed. A single '$' will
indicate to forward all bulletin groups that go to the particular BBS
as assigned in BULLFWDS.BTR. You can remove all of the $THIS, $THAT
lines.
The JA, JB, etc command may be followed by an optional
number of how many calls to list (ie JA 5, etc).
Control-C can be used to abort entry of a message locally. It can also
be used to abort reading a message, etc.
The help command is now driven by one HELP file. I haven't had time to
create a decent help file. You can probably figure out the syntax by
looking at the sample one I threw together quickly.
There are a few new Lx commands. LU is list Unread, LK is list Killed (but
not yet deleted).
You will find that L@ call, L< call, and L> call will go from oldest to
newest. This is because of the way they are indexed.
No LOCAL window yet.
Configuration file has been changed. You should be able to figure it out.
First line is No of TNCs. If you use more than one you need to repeat
the next 4 lines for each.....
1 (No of TNCs in use)
ABLG <- First char is Port (A-F)
Next chars are B=BBS only L=Local G=Guest
B means BBS only.
L means BBS plus LOCAL only
(BBSs are always allowed).
G may be added to either B or L
to add guest access.
Do not use both B and L.
1 4800 14 <- Port#, baudrate, video attribute
145.01 Mhz <- Port info
LstMsg# $L Mail: $Q <- Mail beacon if any
------ <- end of beacon text (used instead of ***EOF)
[Logan, Utah]
... etc
---------------------------------
Message Types
There are only 3 messages types. Type B (Bulletins), Type P (Private), and
Type T (Traffic). If you enter a message using only S or S followed by a
letter other than B, P, or T, the message will default as follows:
If the TO address appears to be a valid callsign (at least 4 characters,
1 or 2 numeric characters, doesn't end in a numeric), the message will
become SP. If it does not appear to be a callsign, it will become SB.
S ALL - same as SB ALL (No numerics, only 3 characters)
S W1AW - same as SP W1AW (Valid call)
S PK232 - same as SB PK232 (Ends in numeric)
S TNC2A - same as SP TNC2A (Looks like a valid call)
---------------------------------
$BIDs
Some folks seem determined to try to use the $BID feature as an MID
(Message ID). This does not follow the intended usage. The $BID is
intended to indicate 'flood' or distribution list type forwarding.
A BID is *NOT* assigned to all bulletins. If you wish to send a
bulletin to all users at only one particular BBS, you should not
use a BID:
SB ALL @ W3IWI
The only case a BID should be assigned to a Private message is for
the special case of private mail addressed to SYSOP. To distribute
a message to a group of SYSOPs, the proper method is:
SP SYSOP @ MBLBBS $
[Note: Please use 'SYSOP' and not 'SYSOPS' !!]
A message with a $BID acts like the old 'SF' type forwarding and a
copy of the message will be retained subject to the expiration date
feature mentioned below.
A bulletin without a BID with an @BBS, will be forwarded in the same
manner as normal mail and deleted after forwarding (subject to the
parms in the CONFIG file).
This release has been modified to ignore a BID on Private mail
addressed to other than 'SYSOP' and to ignore a BID on Traffic.
I hope to get the MID issue settled and implemented in the
near future.
---------------------------------
Bulletins & 'Killed' Mail
There are a number of ways to prevent old bulletins from being
resurrected and flooding the system again.
First, if a bulletin has been forwarded to all of the systems
that you forward to it will be marked as Fully Forwarded (you
will see a Status of 'F'), and it will no longer be forwarded
even if you add a new BBS to the list.
Second, a bulletin has an expiration date. This is set in the
configuration file as (nn) days from the date the bulletin is
received. After the expiration date, the bulletin will be
marked as expired (Status 'X'), and will also no longer be
forwarded.
To give you flexibility in how long a bulletin will be available
for users to see, you can set an additional number of days between
the date the bulletin expires and the date that it is "killed."
Finally, mail that is "killed" actually remains on the system for
an additional number of days before it is physically deleted and
optionally saved to an oldmail file. "Killed" mail may be listed
with the "LK" command.
This extra period helps retain the BID for an extra period so if
someone happens to be late in forwarding the bulletin to you, your
system will still be able to reject it as a dupe.
Code I am currently testing will extend this feature into using a
Message ID for ALL mail. I've noticed that mail coming through a
long NET/ROM path tends to be duplicated because the sender times
out while the message is still in the network. The ability to save
messages for a few days before actually deleting them will allow
mail that you forward to stick around long enough for dupe checking.
For example if your config file was set as follows:
4 (No of days before actual delete/save of 'killed' mail)
7 (Default no of days for bulletin expiration date)
14 (No of days before expired bulletins are 'killed')
The bulletin would expire 7 days after receipt. Your system would
attempt to forward it for a maximum of 7 days or until all BBSs
your forward it to had received it.
Users would still be able to read the bulletin for an additional
14 days. It would then be 'killed'.
The 'killed' bulletin would be deleted 4 days later, and would be
optionally saved into the OLD BULLETIN save file if desired.
SAVEBULL.OLD (killed bulletins save file)
SAVETFC.OLD (killed traffic)
SAVEFWD.OLD (killed fwded mail)
SAVELOC.OLD (killed other mail - local originated or local destination)
The K! command does the daily housekeeping. (Checking for expired bulletins,
deleting, saving, etc.) It can be entered as a local command, or can be
placed in the forwarding file as:
--------
K!
23 <- the hour to do it
--------
If you are running multiple ports sharing one set of data file, be sure to
run K! from ONE forwarding file ONLY!
------------------------------------------------------------------------
The new log format:
All log lines begin with the Month and Day (no Year), followed
by the time (including seconds).
MMDDHHMMSS........
Text-To-Mail (T)
0401165034MT 34490B T:ALL@MBBS F:WA7MXZ@W1AW <12345> S:SUBJECT
Received (S)
0401165034MS 34491P T:W3IWI@W3IWI F:WA7MXZ@WA7MXZ <34491> S:TESTING
Reverse Forwarded (<)
0401165034M< 34492P T:SYSOP@NET F:W1XX@W1AW <2345> V:W0RLI S:TEST
Forwarded (F= normal forward $= BID forward)
0401192648MF 34488P V:WB7TRX <12345>
0401192648M$ 34489B V:WB7TRX <12346>
Forwarded to File (F= normal forward $= BID forward)
(X: instead of V:)
0401192648MF 34488P X:WB7TRX
0401192648M$ 34489B X:WB7TRX
Some actual examples:
------ LOG.A ------
0413144602SI *** BBS Initialize
[Bob connects and forwards some NUThole traffic]
0413145618CA WA7MXZ-3
0413145720MS 34638B T:ALL@ARRL F:WB8SCG@WB0TAX <8107> S:ARRL PROPOGATION FORCAST NR 15
0413145752MS 34639B T:ALL@ARRL F:WB8SCG@WB0TAX <8109> S:ARRL SATELLITE BULLETIN NR 102
0413145830MS 34640B T:ALL@ARRL F:KG3M@W3IWI <32508> S:ARRL BULLETIN #35
0413145904MS 34641B T:SYSOP@MBLBBS F:NA2B@W4MWP <4094> S:22:33LFA HELP
0413145934MS 34642B T:ALL@ARRL F:WB8SCG@WB0TAX <8166> S:ARRL SATELLITE BULLETIN NR 103
0413150004MS 34643B T:ALL@NET F:VE3GYQ@VE3GYQ <6768> S:RE CHARTER
0413150034MS 34644B T:ALL@NET F:VE3GYQ@VE3GYQ <6767> S:ATTENTION TO DETAILS
0413150042XD
[I forward some of the above to TRX]
0413152852M$ 34638B V:WB7TRX <5601>
0413153008M$ 34639B V:WB7TRX <5602>
0413153156M$ 34640B V:WB7TRX <5603>
0413153342M$ 34641B V:WB7TRX <5604>
0413153458M$ 34642B V:WB7TRX <5605>
------ LOG.B ------
[A message I entered locally]
0413152128MS 34646P T:WA7MXZ F:WA7MBL@WA7MBL <34646> S:5.02 BUG FIXES
[RLI connects and forwards traffic]
0413162134CB W0RLI
0413162326MS 34648B T:ALL@NET F:N6MXG@N6YN <667> S:ATTENTION ATARI USERS...
0413162450MS 34649B T:ALL@NET F:N6MXG@N6YN <950> S:SPLIT SCREEN TERM. PROG. FOR ATARI
0413162538MS 34650B T:ALL@NET F:WA6BRI@N6YN <993> S:HELP
0413162742MS 34652B T:ALL@NET F:KF5TL@KD5LF <1929> S:LOGGING PGM.
0413162840XD
The letter following the message number is message type (B,P,T)
The message number in <brackets> is either the message number at the
originating BBS (assuming 'standard' message headers are in use) on
messages received or the message number assigned by the BBS the
message was forwarded to (assuming MBL BID type forwarding: OK 12345
is being used by the receiving BBS) on forwarded messages.
------------------------------------------------------------------------
I have added forwarding type "R" which is Reverse Forwarding info only, with
no forwarding attempt made.
R W3IWI
00-23
W3IWI
W1AW
$
------------------------------------------------------------------------
Mail addressed to 'SYSOPS' will be changed to 'SYSOP'.
------------------------------------------------------------------------
LX (list expired) command has been added.
------------------------------------------------------------------------
LM, LN, L<, L>, and L@ may have a range of message numbers (LM nnnn nnnn).
This group of commands will still list messages from oldest to newest (due
to the way they are indexed).
------------------------------------------------------------------------
A message that is killed can be edited back to life.
However, you cannot edit a message to Killed status. Editing the status of
a hidden message will un-hide it.
-----------------------------------------------------------------------
DP command does paged download (local).
Mail beacon is now sent in Converse rather than Transparent mode.
------------------------------------------------------------------------
It is now ok to use "24" as a forwarding time for any size mail. This entry
will be ignored. The forwarding file may look something like:
GA WA7MXZ
00-23<5 <-- fwd < 5K
24 <-- nothing over 5K will forward at any time
@ WA7MXZ-2
....
------------------------------------------------------------------------
Additional commands may be sent to individual TNCs upon BBS startup or
shutdown by placing the commands into text files. If the files are found
they will be sent to the TNC in command mode. In the case of startup,
the commands in the file will be sent before the commands loaded from the
configuration file.
INIT.A will be sent to TNC A upon startup
FINI.A will be sent to TNC A upon shutdown
These filenames are hardcoded.
------------------------------------------------------------------------
The F command (Make File from Message) has been removed. There are now 3
flavors of the M command to replace it.
M <msgno> <filename> saves the message same format as the R command
MV <msgno> <filename> uses a verbose format to include all headers
MT <msgno> <filename> is Text only (except for Date and From info)
I find MT useful for moving ARRL & AMSAT bulletins into the file area
without having all of the 'garbage' included.
If the filename specified exists, you will be asked if you wish to
Append. If you answer no, the operation will be aborted. (If you wish
to overwrite, you must first Zap the old file with the Z command.)
Examples follow:
---- this is M format ----
[35004] BF BID: ARRL.046
Path: WA7MXZ!W3IWI!WA4ONG!WB0TAX
Date: 18 May 88 18:41:16 Z
From: WB8SCG@WB0TAX
To: ALL@ARRL
Subject: ARRL BULLETIN NR 46
HR ARRL BULLETIN NR 46 FROM ARRL HEADQUARTERS
NEWINGTON CT MAY 13, 1988
TO ALL RADIO AMATEURS BT
PREREGISTERED CLUBS IN WISCONSIN WILL BE SIGNING THE SPECIAL 200
BICENTENNIAL PREFIX FROM 0001 UTC MAY 14 THROUGH 2359 UTC MAY 20.
...
AR
---- this is MV format ----
Msg# TS Size TO @ BBS From Date Subject
35004 BF$ 726 ALL @ARRL WB8SCG 18-May ARRL BULLETIN NR 46
Bulletin ID: ARRL.046
R:880518/1841z 35004@WA7MXZ [Logan, Utah]
R:880516/1914z 36216@W3IWI [Balto/Wash]
R:880516/1648z 11611@WA4ONG [Richmond, VA] F:145.01 N:RIC,BRDN
R:880516/1145r 9705@WB0TAX Tidewater BBS [Hampton, Va. 23666]
HR ARRL BULLETIN NR 46 FROM ARRL HEADQUARTERS
NEWINGTON CT MAY 13, 1988
TO ALL RADIO AMATEURS BT
...
---- this is MT format ----
Date: 18 May 88 18:41:16 Z
From: WB8SCG@WB0TAX
HR ARRL BULLETIN NR 46 FROM ARRL HEADQUARTERS
NEWINGTON CT MAY 13, 1988
TO ALL RADIO AMATEURS BT
...
------------------------------------------------------------------------
I have made major changes to the operation of the SERVER and REQ???
type stuff. The server processors are now EXTERNAL to the BBS code.
This saves some space for folks not wanting to offer REQFIL & REQDIR.
It also allows more flexibility to write any type of server code.
Changes have been made to the configuration file. The 'SERVER' file line
has been removed. A set of Server lines has been added. The programs
REQFIL.EXE and SORRY.EXE have been included. Details at the end of this
file.
------------------------------------------------------------------------
If a user enters ^Z in the Subject line when entering a message, it will
abort message entry.
------------------------------------------------------------------------
The line count for 'PRESS RETURN' should work properly when doing L lists.
(however, it still has a problem with reading messages or files which have
long lines that wrap around.)
----------------------
DETAILS of the new and improved SERVER feature........
A sample portion of the configuration file:
TEST.COM (OS Program)
FWD.A (forwarding file)
FWD.A (reverse forwarding file)
TEXTMAIL.ERR (file to catch Text-to-Mail errors)
LOG.A (file for logging)
MAILFILE.BTR (mail header file)
USERFILE.BTR (user data file)
BULLSTNS.BTR (bull data file)
BULLFWDS.BTR (bull fwding file)
SWAP.BBS (@BBS swap file)
INFO.HLP (info file - I command)
HELP.HLP (help file - H command)
GHELP.HLP (guest help file - H command)
\BBS\FILES\ (path/drive for upload/download files - if path, must exist!)
\BBS\YFILES\ (path for YAPP files )
\BBS\MAIL\ (path for mail )
SAVEBULL.OLD
SAVETFC.OLD
SAVEFWD.OLD
SAVELOC.OLD
------ Beginning of Servers
REQFIL {To address}
REQFIL.IN {File to forward message to}
REQFIL.OUT {File to grab reply from}
REQFIL.EXE {Program to run (parameters on next line)}
W3IWI \BBS\FILES\
REQDIR {To address}
SORRY.IN {File to forward message to}
SORRY.OUT {File to grab reply from}
SORRY.EXE {Program to run (parameters on next line)}
W3IWI REQDIR
REQJNK {To address}
REQJNK.IN {File to forward message to}
NULL {File to grab reply from}
NULL {Program to run (parameters on next line)}
NULL
COPY {To address}
COPY.IN {File to forward message to}
COPY.IN {File to grab reply from}
NULL {Program to run (parameters on next line)}
NULL
------ End of Servers
3 (Days before actual delete of 'killed')
5 (# days for bull exp date)
The old "SERVER" type of export is now removed. All export is done
using the standard "import/export" type file.
A section of the config file can have any number of servers (within
reason). Each server has 5 lines associated with it. The first line
is the "To address" of the server. The next line is the file that
mail addressed to the server will IMMEDIATELY be forwarded to. The
next 3 lines are the reply file from the server, the name of the server
program to run, and the command line to pass to the server. If the
reply file is NULL, it will be ignored. Also, if the Program name is
NULL, no program will run.
If you are writing your own server that takes more than a few seconds,
you may wish to simply use the server for a quick export, and then do
the 'real' processing from a DOS call in your forwarding file.
So far I have written the REQFIL server and a SORRY server. REQFIL reads
REQFIL.IN, processes the request, and creates REQFIL.OUT. SORRY reads
SORRY.IN and creates SORRY.OUT.
The sample config file above implements four 'servers'.....
The first server is REQFIL. The parameter line is the callsign of the
BBS (for creating the FROM address) and the path of the \bbs\files\.
The second server is SORRY. It is used to give a "SORRY - I dont support
the x feature" reply. The parameter line is the callsign of the
BBS (for creating the FROM address) and the feature name. The example
shows how to give the SORRY reponse to the REQDIR feature. If you don't
wish to support REQFIL, you may want to use the SORRY server for it also.
The third example demonstrates how to cause immediate forwarding of
messages addressed to REQJNK to REQJNK.IN. Because the following lines
are NULL, no program is run, and no reply file is processed.
The final 'server' is a bit of insanity. It forwards a copy of a
messages addressed to 'COPY' to the COPY.IN file. The program line is
NULL, so no program is run. It then again uses COPY.IN as the reply file and
sucks back the message that it originally forwarded out still addressed
to COPY. The net result is that it adds a forwarding header line and
wastes a message number. Although it is addressed to COPY, a message
coming back from server processing will not trigger additional processing.
However, if you use server to forward it out, and use the forwarding
file to NUThole it back in, it should continue to be processed over and
over again.
------------------------------------------------------------------------
'User' portion of forwarding append header (QTH and other junk) expanded
from 40 to 50 characters so sysops can add more junk. (Just what we need?)
------------------------------------------------------------------------
^C abort should now work on 'DU' series of commands.
------------------------------------------------------------------------
"L<" and "L>" lists will now include Killed messages (sysop only).